1. Field of the Invention
The present invention relates to methods and apparatus for use in a push to talk type service, for example a so-called push to talk over cellular service.
2. Description of the Related Art
Walkie-talkie type services have long proved popular amongst users who wish to communicate brief messages quickly between one another. Conventionally, such services have been provided by two-way portable radios which utilise a dedicated part of the radio spectrum, but which only allow users to communicate with a small group of pre-selected users who utilise similar terminals and who are within range of the relatively short operating range of the radios. More recently, services have been introduced into the United States which piggy-back on the existing cellular telephone infrastructure. However, these services have been proprietary in nature and have not allowed users to communicate between different operator networks.
In an attempt to broaden the use of walkie-talkie type services, an industry grouping known as the Open Mobile Alliance (www.openmobilealliance.org) has been established with the aim of standardising suitable protocols which will allow inter-network operability for Walkie-Talkie services offered over cellular networks. The service established by the various standards is known as Push to talk Over cellular (PoC). PoC proposes that associated speech data will be transported over a packet switched access network. In the case of GSM and UMTS, this will be the general packet radio service (GPRS) or 3G access network. In other network architectures, analogous packet switched access networks will be utilised for transporting talk data. Push to Talk services may also be offered over circuit switched access networks, although this is not the preferred option.
The Push to talk over Cellular (PoC) system is typically implemented on GSM/GPRS/3G networks and which makes use of the IP Multimedia Subsystem (IMS) standardised by the 3rd Generation Partnership Project to facilitate the introduction of advanced data services into cellular networks, and in particular of real-time multimedia services. The IMS relies upon the Session Initiation Protocol (SIP) which has been defined by the Internet Engineering Task Force (IETF) for the setting up and control of multimedia IP-based sessions. A PoC Server is located within the IMS or is attached thereto, and implements the functionality for setting up and controlling PoC Sessions.
Existing push-to-talk (PTT) and conferencing systems typically use a control mechanism to grant one of the users the right to speak while other users in the communication are denied such right and are in listening mode. Such control mechanism is typically referred to as floor control, talker arbitration, talk burst control, etc. For example, the Open Mobile Alliance is currently working on a specification of Push-To-Talk over Cellular (PoC) system, which includes Talk Burst Control Protocol (TBCP).
To request the right to speak on behalf of the user, the terminal (PoC Client) typically sends a request message to the controller (PoC Server). The controller typically responds either granting or rejecting the request. The controller typically restricts the time the user is allowed to talk, typically by starting an allowed talk timer when it grants the request, and uses some mechanism to interrupt the user, typically by sending a revoke message to the user's terminal or by simply not forwarding the user's media. The user who is interrupted by the controller is typically penalized by the controller in some way, e.g. by not granting the user the right to speak for a certain period of time.
The next version of OMA PoC (herein called “PoC 2”, with the previous version being called “PoC 1”) is evolving in OMA. Part of the new functionality in PoC 2 is to include new media types, allowing the sending of pictures, video etc in the PoC Sessions. The following extract is from the OMA PoC 2 Requirement Document [OMA-RD-PoC-V2—0-20050902-D Push to Talk Over Cellular 2 Requirements, Draft Version 2.0-02. September 2005]: “PoC 2 service facilitates communication among PoC Users using media types, in addition to voice. The additional media types supported could be still images, live-streamed video, file transfer and text, but not limited to the above mentioned list. Video media stream in PoC 2 context implies only the visual component without any reference to audio. A PoC 2 Server provides support for more than one media type in a PoC Session. PoC 2 Clients can support more than one media type in a Session, based on the capabilities of the User Equipment.” Also from the OMA PoC 2 Requirement Document: “The PoC Client MAY send images or series of images that are available in the User Equipment (e.g. from a camera) to the Participants of the PoC Session.”; “The PoC Server SHALL support the transfer of images or series of images sent by the PoC Client.”; “The PoC Client MAY be able to send files that are available in the User Equipment (e.g. a MS word document, a game software package) to the Participants of the PoC Session.”; and “The PoC Server SHALL support the transfer of files that are available in the User Equipment (e.g. a MS word document, a game software package).”
As mentioned above, the media sent in a PoC Session is managed by a floor control mechanism. Only the user that currently has the floor is able to send media. In PoC 1, the only media sent is speech; the floor is allocated to a user for a certain time, and during that time the user can talk and the other will receives the talk bursts.
A problem arises if the same mechanism is used for new media types such as pictures in PoC 2. If a user requests the floor for sending a picture of any reasonable size, it is likely that the time the user will have the floor will be insufficient for transferring the picture, and as result only a part of the picture will be received by the session participants. The same will be true for all framed media such as files, video clips etc.
It is desirable to address this problem.